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ABSTRACT 

Battlegroup  sparing  is  an  inventory  strategy  that  can  significantly  reduce  the  initial 
outfitting  costs  of  a  weapon  system  by  greatly  reducing  the  range  and  depth  of  spares 
required  to  outfit  individual  ships.  This  strategy  moves  low  demand  items  from  shipboard 
spare  part  inventories  to  intermediate  level  inventories  which  support  an  entire 
battlegroup.  This  thesis  extends  the  techniques  of  Readiness  Based  Sparing  (RBS)  and 
proposes  a  method  for  defining  suites  of  spares  at  both  the  shipboard  and  battlegroup  level 
which  augment  each  other  to  achieve  a  desired  level  of  system  readiness  while  realizing 
the  efficiencies  of  battlegroup  sparing.  To  evaluate  the  impacts  of  this  strategy,  this  thesis 
develops  a  computer  simulation,  which  can  be  utilized  to  evaluate  the  budget  and 
readiness  impacts  of  applying  this  or  any  other  inventory  strategy  to  a  weapon  system. 
The  methodology  proposed  by  this  thesis  was  then  applied  to  the  Cooperative 
Engagement  System  (CES),  reducing  initial  outfitting  costs  by  nearly  50%,  an  overall 
savings  of  over  thirty  million  dollars  in  scarce  outfitting  funds. 
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EXECUTIVE  SUMMARY 


Since  the  establishment  of  operational  availability  as  the  Navy's  uniform  measure 
of  material  readiness,  the  logistics  community  has  made  dramatic  changes  in  the 
methodology  used  to  determine  the  range  and  depth  of  spare  parts  carried  onboard  ships. 
Readiness  Based  Sparing  (RBS)  is  currently  the  accepted  method  of  achieving  operational 
availability  goals  at  the  minimum  cost. 

Traditionally,  the  Navy  has  optimized  its  spare  part  inventories  on  a  ship-by- ship 
basis,  due  to  the  independent  nature  of  ship  operations.  Dramatically  improved 
information  systems  and  logistics  channels  that  provide  rapid  support  to  deployed  ships 
have  reduced  the  logistics  response  time  seen  by  independently  operating  ships.  The 
steady  decrease  of  spares  budgets  and  this  reduced  logistics  response  time  has  lead  to  the 
Navy's  exploration  the  application  of  multi-echelon  sparing  techniques  to  shipboard  spares 
inventories 

Battlegroup  Sparing  is  a  multi-echelon  sparing  technique  which  decreases  the 
spares  requirements  of  individual  ships  by  providing  in-theatre  support  of  the  typically 
high  cost,  low  demand  items  that  are  currently  forced  aboard  ships  by  RBS  to  attain 
operational  availabili  y  goals  set  by  weapon  system  program  sponsors.  Prior  to  this  thesis, 
this  concept  was  untested  as  the  models  currently  used  in  RBS  (ACIM  and  Tiger)  cannot 
handle  a  multi-shij.  environment.  This  thesis  developed  the  3attlegroup  Sparing 
Simulation  Model  (BSSM)  which  provided  a  means  for  evaluating  the  impacts  of  multi- 
echelon  sparing  techi  lques  in  a  shipboard  environment. 
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In  conjunction  with  BSSM,  this  thesis  also  developed  a  methodology  which  could 
be  used  for  determining  the  proper  range  and  depth  of  spares  to  maximize  the  savings  of  a 
multi-echelon  sparing  approach.  This  methodology,  when  used  on  the  Cooperative 
Engagement  System  (CES),  produced  a  range  and  depth  of  spares  that  achieved  a  given 
operational  availability  goal  at  less  than  fifty  percent  of  the  cost  of  the  traditional  method. 
If  applied  by  the  CES  program  office,  this  method  could  result  in  savings  of  over  $30 
Million  to  the  Navy's  initial  outfitting  funds. 
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I.  INTRODUCTION 

A.  BACKGROUND 

The  Chief  of  Naval  Operations  (CNO)  has  cognizance  over  the  U.S.  Navy's 
acquisition  programs.  It  exercises  this  authority  through  various  program  offices  that 
manage  the  acquisition  and  lifecycle  support  of  the  U.S.  Navy's  weapon  systems.  Prior 
to  the  early  1980's,  these  program  offices  lacked  a  common  approach  to  setting  material 
requirements,  which  was  noted  by  the  CNO's  Logistics  Review  Group  (LRG)  as  a 
primary  cause  for  the  decreasing  state  of  readiness  of  the  weapon  systems  of  the  day. 
The  LRG  found  that  these  "programs  generally  lacked  any  substantive  link  between 
readiness  requirements,  the  reliability  levels  specified  by  contract,  and  their  logistics 
resources  and  planning  necessary  to  achieve  the  required  readiness  in  the  Fleet." 
[Provisioning  and  Fitting  Out  Support  Manual]  In  response  to  these  findings  the  CNO 
published  OPNAV  Instruction  3000.12  which,  among  other  things,  established 
Operational  Availability  (Ao)  as  the  single  measure  of  readiness  for  U.S.  Navy  weapon 
system  programs.  Ao  is  defined  in  this  instruction  as  "the  probability  that  the  system  is 
ready  to  perform  its  intended  function  in  its  operational  environment  when  called  for  at 
any  point  during  a  mission."  [OPNAVTNST  3000.12] 

The  establishment  of  Ao  as  the  uniform  measure  of  materia!  readiness  forced  the 
U.S.  Navy  to  make  dramatic  changes  in  the  methodology  used  to  determine  the  range  and 
depth  of  spare  part  inventories  held  onboard  its  ships.1  Inventory  models  used  prior  to 
this   period    were   primarily   demand    based    with   the   goal    of  maximizing    supply 


1  In  this  thesis,  spare  pan  inventories  held  onboard  ships  will  be  referred  to  as  "allowed  items"  or 
"allowance  list  items." 
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effectiveness;  unfortunately  supply  effectiveness  was  not  uniformly  defined  and  could 
not  be  directly  related  to  Ao. 

To  resolve  this  problem  the  U.S.  Navy  developed  the  Availability  Centered 
Inventory  Model  (ACIM).  Utilizing  Equation  (1.1),  the  model  relates  a  supply  system 
metric,  Mean  Logistics  Delay  Time  (MLDT),  to  system  readiness.2  ACIM  assumes  the 
design  of  the  system  is  fixed  which  allows  it  to  consider  MTBF  and  MTTR  as  constants, 
maximizing  system  readiness  by  minimizing  MLDT. 


MTBF 
Ao  = 


MTBF  +  MTTR  +  MLDT      0-1) 

During  the  period  that  ACIM  was  being  created,  the  Naval  Sea  Systems 
Command  was  developing  the  Tiger  model.  This  model  accounts  for  the  structure  and 
intended  mission  cycle  of  a  weapon  system,  then  utilizes  a  Monte  Carlo  simulation  to 
make  Reliability  Maintainability  and  Availability  (RMA)  assessments  of  that  system.  Of 
particular  interest  to  the  logistics  community  was  the  ability  of  the  Tiger  model  to  assess 
the  readiness  of  a  system  for  a  given  inventory's  Gross  Effectiveness3  (GE). 

The  weaknesses  of  ACIM,  which  will  be  discussed  further  in  Chapter  III,  and  the 
availability  of  the  Tiger  model  lead  to  the  development  of  the  Readiness  Based  Sparing 
(RBS)  methodology,  which  is  presently  used  by  the  U.S.  Navy  and  the  Department  of 
Defense  (DOD)  as  a  whole.  RBS  is  "the  establishment  of  an  optimum  range  and  quantity 
of  spares  and  repair  parts  at  all  stockage  and  user  locations  in  order  to  meet  approved, 


2  The  terms  of  equation  1 . 1  will  be  discussed  further  in  Chapter  2. 

3  An  inventory's  Gross  Effectiveness  is  the  probability  that  the  required  part  is  available  from  the  ship's 
inventory  given  a  system  has  experienced  a  failed  component. 
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quantifiable,  weapon  system  readiness,  operational  availability,  or  fully  mission  capable 
objectives."  [DOD  Directive  4140. 1R] 

The  Naval  Supply  Systems  Command  established  procedures  for  applying  RBS 
and  created  a  PC  based  workstation  to  allow  weapon  system  program  managers  to  apply 
RBS  techniques  to  their  specific  weapon  systems.  The  workstation  uses  a  combination  of 
ACIM  and  Tiger.  ACIM  is  used  to  determine  the  order  in  which  spares  are  added  to  the 
ship's  allowance  list  while  Tiger  is  used  to  evaluate  the  system  readiness  achieved  by  a 
given  level  of  sparing. 

The  process  begins  by  establishing  bounds  for  the  system  Ao  by  first  running  the 
Tiger  model  with  zero  spares  on  board  (0%  GE)  to  deduce  the  system's  zero  spares 
availability  (Az).  This  is  followed  by  a  run  with  an  unlimited  amount  of  spares  onboard 
(100%  GE)  to  deduce  the  system's  inherent  availability  A.  ACIM  and  Tiger  are  then 
linked  together  by  the  OPT  program,  which  is  used  to  rank  potential  spares  in  order  of 
their  contribution  to  system  Ao.  This  data  is  used  to  create  the  OPT  listing  which  is  a 
listing  of  individual  parts  and  their  unit  cost  in  order  of  their  contribution  to  system 
readiness.  This  listing  can  then  be  used  to  create  the  budget-to-readiness  curve.  Figure 
1.1  is  an  example  of  a  typical  budget-to-readiness  curve.  The  shape  of  the  typical 
budget-to-readiness  curve  makes  intuitive  sense  as  one  would  expect  to  see  decreasing 
marginal  returns  as  inventory  investment  increases.  The  marginal  analysis  technique 
used  by  RBS  has  a  tendency  to  select  inexpensive  items  prior  to  expensive  items,  since 
they  tend  to  make  a  higher  contribution  to  readiness  per  dollar  spent.  Thus  the  upper 
portion  of  the  budget-to-readiness  is  typically  made  up  of  high  cost,  highly  reliable  spare 
parts. 
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Figure  1.1  A  Typical  Budget-to- Readiness  Curve 


B.  PROBLEM  STATEMENT 

In  today's  atmosphere  of  declining  DOD  budgets  and  military  downsizing,  it  does 
not  make  sense  to  continue  to  spend  scarce  inventory  dollars  on  these  expensive  spare 
parts  that  are  not  likely  to  fail.  Recognizing  this  potential  cost  savings,  a  multitude  of 
naval  studies  over  the  past  decade  have  yielded  impressive  cost  savings  by  removing 
these  highly  reliable,  but  expensive  items  from  shipboard  inventories.  However  they 
have  a  common  consequence:  the  ship  can  no  longer  realize  required  Ao  goals. 

One  concept  that  is  currently  under  consideration  by  the  Naval  Supply  Systems 
Command  and  many  weapon  system  program  managers  is  Battlegroup  Sparing. 
Battlegroup  Sparing  places  those  highly  reliable  but  expensive  items  in  a  central  location 


to  support  an  entire  battlegroup.  This  concept  remains  undeveloped,  as  there  is  currently 
no  means  to  evaluate  the  impact  on  readiness  of  this  type  of  sparing.  The  purpose  of  this 
thesis  is  to  further  explore  the  concept  and  to  develop  an  algorithm  and  simulation 
program  to  evaluate  the  potential  cost  savings  and  readiness  impact  of  Battlegroup 
Sparing. 

C.  METHODOLOGY 

To  evaluate  the  impact  of  Battlegroup  Sparing  it  was  first  necessary  to  create  a 
model  that  could  simulate  a  battlegroup  of  ships,  each  possessing  a  given  set  of  weapon 
systems.  The  weapon  systems  on  these  ships  would  not  only  be  supported  by  the  ship's 
own  inventory,  but  also  by  an  intermediate  level  of  supply  that  was  drawn  upon  by  all 
ships  in  the  battlegroup.  The  purpose  of  the  model  is  to  determine  the  rate  at  which  the 
battlegroup  spares  are  depleted  considering  that  all  ships  in  the  battlegroup  were 
competing  for  the  same  spares,  and  the  impact  of  the  depletion  rate  on  the  readiness  of 
the  individual  ships.  For  this  reason  the  Battlegroup  Sparing  Simulation  Model  (BSSM) 
was  written. 

Following  the  creation  of  the  BSSM,  the  next  step  was  to  select  a  weapon  system 
to  explore  the  concept  of  Battlegroup  Sparing.  To  following  criteria  were  developed  to 
maximize  the  potential  benefits: 

1 .  RBS  data  for  the  system  must  currently  exist. 

2.  Systems  should  be  common  across  many  different  ship  types. 

3.  System  should  be  highly  reliable  with  flat  budget-to-readiness  curves. 


4  This  model  will  be  discussed  in  greater  detail  in  Chapter  IV. 
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The  Cooperative  Engagement  System  (CES)  was  a  weapon  system  that  met  all  of  the 
above  criteria  and  was  also  early  enough  in  the  acquisition  process  for  this  study  to 
influence  its  initial  outfitting  requirements  prior  to  their  acquisition.  These  factors  made 
it  the  obvious  choice  for  this  study. 

The  standard  RBS  methodology  was  then  used  to  develop  a  listing  of  shipboard 
spares  to  determine  the  per  ship  outfitting  cost  of  traditional  methods.  An  OPT  list  was 
also  created  to  determine  the  order  which  these  spares  would  be  moved  to  the 
intermediate  level  during  the  experiment.  The  battlegroup  simulation  was  then  run 
several  times.  At  each  iteration,  an  additional  spare  was  moved  from  the  shipboard 
inventory  to  the  intermediate  inventory,  reducing  redundant  inventory  in  the  battlegroup. 
The  result  of  this  process  was  a  new  budget-to-readiness  curve  that  considers  the  entire 
battlegroup.  This  curve  was  then  used  to  draw  conclusions  on  the  budget  and  readiness 
impacts  of  battlegroup  sparing. 

D.  THESIS  STRUCTURE 

The  organization  of  the  remainder  of  this  thesis  is  as  follows.  Chapter  II  will  discuss 
readiness  concepts  and  relate  them  to  the  Cooperative  Engagement  System  (CES). 
Reliability  Block  Diagrams  (RBD's)  will  then  be  discussed  and  the  CES  will  be  broken 
down  into  its  RBD.  Chapter  III  will  discuss  the  elements  of  RBS,  the  RBS  workstation 
and  the  weaknesses  of  RBS  as  it  is  currently  used.  Chapter  IV  will  describe  the  BSSM 
and  the  methodology  used  to  validate  it.  Chapter  V  will  describe  the  method  of 
combining  the  RBS  process  with  the  BSSM,  using  the  CES.  Finally,  Chapter  VI  will 
discuss  the  conclusions  and  recommendation  that  stem  from  the  results  of  this  study. 


H.         READINESS  CONCEPTS 

A.  OVERVIEW 

The  readiness  of  a  system  is  a  function  of  that  system's  reliability,  maintainability 
and  supportability.  These  terms  are  defined  as  follows  [Provisioning  and  Fitting  Out 
Support  Manual]: 

•  Reliability  is  the  duration  or  probability  of  failure  free  system  performance  under 
a  given  set  of  conditions. 

•  Maintainability  is  the  ability  of  an  item  to  be  retained  in  or  restored  to  a  specified 
operating  condition  when  maintenance  is  performed  by  personnel  having 
specified  skil  levels,  using  prescribed  procedures  and  resources,  at  each 
prescribed  le\  el  of  maintenance  and  repair. 

•  Supportability  is  the  effectiveness  of  the  logistics  support  provided  for  a  weapon 
system.  It  represents  the  remaining  downtime  where  no  active  maintenance 
(including  fault  isolation)  is  being  performed. 

A  system's  Mean  Time  Between  Failures  (MTBF)  is  the  average  time  between 
successive  failures,  which  equates  to  system  reliability.  A  system's  Mean  Time  To 
Repair  (MTTR)  is  the  average  time  required  to  repair  a  system  in  its  operating 
environment  (when  necessary  resources  are  available);  equivalent  to  system 
maintainability.  The  final  factor  of  system  readiness,  system  supportability,  is  equivalent 
to  the  system's  Mean  Logistics  Delay  Time  (MLDT)  which  is  the  average  time  delay 
caused  by  the  logistics  support  system  [OPNAVTNST  3000.12]. 

Having  defined  each  of  the  terms  found  in  Equation  (1.1),  the  relationship 
between  system  readiness  and  that  system's  reliability,  maintainability  and  supportability 
is  now  more  clearly  defined.  Given  this  relationship  and  a  stable  design,  the  logistician  is 
responsible  for  determining  the  appropriate  sparing  levels  to  reach  the  system's  readiness 


goal  at  minimum  cost.  Since  reliability  and  maintainability  are  primarily  functions  of 
system  design,  which  has  been  fixed,  MTBF  and  MTTR  are  considered  to  be  constants. 
This  leaves  MLDT  as  the  only  variable  in  Equation  (1.1)  that  can  be  varied  to  influence 
system  readiness.  ACIM  minimizes  MLDT  for  a  given  budget  constraint  to  optimize 
onboard  stock  levels.  Although  this  method  gives  a  good  solution  to  the  inventory 
problem,  it  assumes  that  all  parts  are  of  equal  importance  to  the  reliability  of  the  system, 
which  is  not  the  case. 

B.  RELIABILITY  BLOCK  DIAGRAMS 

Reliability  Block  Diagrams  (RBD's)  are  a  means  of  considering  the  importance  of 
a  part  to  the  reliability  of  the  system.  "An  RBD  is  a  logic  diagram  which,  by  means  of 
the  arrangement  of  blocks  and  lines,  depicts  the  effect  of  an  item  failure  on  a  system's 
functional  performance."  [Reliability  Block  Diagram  Standard,  May  1987]  The  process 
begins  by  breaking  the  system  down  into  a  set  of  blocks,  which  represent  the  set  of 
functions  it  is  required  to  perform.  Each  block  is  then  broken  down  further  into  blocks 
that  represent  sub-functions  of  the  block.  The  process  continues  until  a  Lowest 
Replaceable  Unit  (LRU)5  is  reached.  When  the  system  has  been  fully  broken  down,  each 
of  the  original  blocks  is  represented  by  a  series  of  block  diagrams  that  represent  the  sub- 
functions  and  LRU's  of  that  block.  Figures  (2. 1)  through  (2.3)  depict  this  hierarchy  for  a 
notional  aircraft  system.  At  the  top  level,  Figure  (2.1),  the  system  has  six  blocks;  an 
airframe,  an  avionics  suite,  two  engines  and  two  hydraulic  systems.    Figure  2.2  is  a 


5  An  LRU  is  a  component  of  the  system  that  can  be  removed  and  replaced  by  shipboard  personnel.  Each 
LRU  in  the  system  is  a  candidate  for  an  onboard  spares  allowance. 
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breakdown  of  engine  #1,  and  Figure  2.3  is  a  breakdown  of  fuel  system  #1.    The  fuel 
nozzle  and  fuel  pump  would  be  considered  to  be  LRU's  of  this  aircraft  system. 

Once  the  supporting  documentation  for  each  of  the  original  blocks  has  been 
completed,  the  blocks  are  connected  with  a  reliability  line.  This  line  represents  the 
interdependency  between  these  equipments  and  the  performance  of  the  system.  If  this 
line  is  broken  by  a  failed  component  the  system  will  fail.  The  reliability  line  is  in  bold 
print  in  Figures  2. 1  through  2.3. 


3.0 

Engine  1 

5.0 

Hydraulics  1 

1.0 

Airframe 

2.0 

Avionics 

4.0 

Engine  2 

6.0 

Hydraulics  2 

Figure  2.1  Example  Reliability  Block  Diagram 
(Upper  Level) 
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3.1                ; 
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Aux  Power 
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Fuel  2 

Figure  2.2  Reliability  Block  Diagram 
Block  3.0  (Engine  #1) 


3.3.1 

Fuel  Nozzle 

3.3.2 

Fuel  Pump 

Figure  2.3  Reliability  Block  Diagram 
Block  3.3  (Fuel  System  #1) 


Once  the  blocks  have  been  linked  together  by  the  reliability  line  the  RBD  is 
complete.  Though  omitted  from  Figures  2.1  through  2.3,  data  including  the  MTBF, 
MTTR  and  duty  cycle  of  the  equipment  is  then  placed  in  each  individual  block.  The  RBS 
workstation,  which  will  be  discussed  further  in  Chapter  IE,  contains  a  utility  called  the 
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Computer  Aided  Readiness  Assessment  Tool  (CARAT)  which  allows  the  workstation 

user  to  build  RBD's  and  create  input  files  reflective  of  this  data  for  use  in  Tiger  and 

ACIM 

C.  OPERATIONAL  AVAILABILITY 

The  purpose  of  creating  an  RBD  for  the  system  is  to  allow  the  models  to  calculate 
system  Ao.  The  definition  given  for  Ao  in  the  introduction  of  this  thesis  is  useful  in 
explaining  the  meaning  of  Ao,  but  does  not  provide  an  exact  method  to  use  when  trying 
to  actually  calculate  tne  Ao  of  a  given  system.  An  equivalent  but  more  useful  definition 
is  "the  percentage  of  time  that  a  system  is  capable  of  performing  its  intended  function." 
[Provisioning  and  Outfitting  Support  Manual,  October  1995]  Given  the  mission  cycle  of 
the  system  in  question,  uptime  is  defined  as  the  amount  of  that  time  that  the  system  is 
capable  of  performing  its  intended  mission,  while  downtime  is  the  amount  of  that  time 
that  the  system  is  not  capable.  Using  these  definitions  of  uptime  and  downtime,  Equation 
1.1  can  be  simplified  to  Equation  2.1,  which  is  used  to  calculate  system  Ao  by  the 
simulation  models  discussed  in  Chapters  HI  and  IV. 


Uptime 
Ao  = - (2.1) 

Uptime  +  Downtime 


D.  COOPERATIVE  ENGAGEMENT  SYSTEM  (CES) 

The  Cooperative  Engagement  System  (CES)  is  designed  to  "significantly  improve 
Battle  Force  Ant i- Air  Warfare  (AAW)  capability  by  coordinating  all  force  AAW  sensors 
into  a  single  real-tin;e  fire  control  quality  composite  track  picture."  [CES  Integrated 
Logistics   Support  Plan]      The  system  consists  of  two  major  subsystems,  the  data 
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distribution  system  (DDS)  and  the  cooperative  engagement  processor  (CEP).  The  DDS 
allows  individual  units  to  transfer  battlefield  information  to  one  another  via  line  of  sight 
directional  signal.  The  CEP  is  a  common  data  process  placed  on  all  units  that  allows 
each  unit  to  see  essentially  the  same  display  of  this  data.  Current  plans  are  to  install  CES 
on  146  surface  ships  with  initial  installs  beginning  in  mid  FY-99  [Mr.  Jeff  Hoare,  13 
Aug  97] 

E.  APPLICATION  OF  RBD  TO  CES 

The  purpose  of  this  thesis  is  to  evaluate  the  consequences  of  applying  battlegroup 
sparing  to  CES.  The  models  that  will  be  discussed  in  Chapters  III  and  IV  were  used  to 
make  this  evaluation,  which  required  the  development  of  an  RBD  for  CES.  The  RBD  of 
CES  used  for  this  thesis  was  created  by  NAVSEALOGCEN  and  is  included  as  Appendix 
(A). 
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HI.       READINESS  BASED  SPARING  (RBS) 

A.  OVERVIEW 

The  RBS  process  consists  of  three  phases:  Readiness  Assessment,  Sparing 
Determination  and  Life  Cycle  Maintenance.  Though  the  phases  are  interrelated,  this 
thesis  is  primarily  concerned  with  the  Sparing  Determination  phase.  During  this  phase, 
Tiger  and  ACIM  are  used  in  conjunction  with  one  another  to  determine  the  spares  suite 
that  achieves  a  desired  level  of  system  readiness  at  the  minimum  cost.  The  RBS 
workstation  was  created  to  allow  program  offices  to  perform  RBS  on  their  weapon 
systems.  This  workstation  includes  the  ACIM,  Tiger  and  OPT  programs  and  an  RBD 
building  utility  called  CARAT. 

B.  AVAILABILITY  CENTERED  INVENTORY  MODEL  (ACIM) 

ACIM  is  "a  stationary  multi-echelon  model  based  on  Markov  process  and 
queuing  theory."  [Castillo,  1989]  Though  the  model  is  capable  of  determining  inventory 
ievels  at  multiple  echelons  of  supply,  it  is  currently  used  only  to  determine  consumer 
level  inventories,  which  are  those  held  onboard  ships.  ACIM  makes  the  following 
assumptions: 

1 .  External  demands  on  supply  are  a  stationary  compound-poisson  process. 

2.  An  allowed  item  is  reordered  when  issued  from  stock  on  a  one-for-one  basis. 

3.  Multiple  locations  of  the  same  part  are  treated  as  unique  items. 

4.  MTTR  and  MTBF  are  treated  as  constants. 

5.  Component  (LRU)  failures  are  independent. 
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Using  these  assumptions,  ACM  calculates  the  contribution  to  readiness  of  each  potential 
spare  by  dividing  its  Mean  Supply  Response  Time  (MSRT)  by  its  unit  cost.  The  MSRT 
for  a  given  part  is  calculated  by  dividing  the  total  expected  logistics  delay  time  by  the 
number  of  requirements  expected  for  that  part. 

For  example,  consider  a  component  with  a  Mean  Time  Between  Failures  (MTBF) 
of  500  hours.  There  is  currently  1  spare  on  the  ship's  allowance  list  and  its  parent  system 
has  a  duty  cycle  of  2000  hours.  The  following  is  a  calculation  of  the  contribution  to 
readiness  of  placing  an  additional  spare  of  this  item  on  the  ship's  allowance  list. 

B   =Zx>s(x-si)P(x^iT)  (3-1) 

Bi  =  Expected  number  of  backorders  of  item  i  at  any  point  in  time. 

s,  r-  Shipboard  stock  level  of  item  i. 

X.,  =  Daily  demand  rate  for  item  i. 

T  =  Stock  protection  period  in  days. 

P(x;/.,T)  =  the  probability  of  x  demands  given  a  failure  rate  of  X, 

during  the  time  period  T. 

The  calculation  begins  by  utilizing  Equation  3.1  [Naval  Supply  Systems 
Command,  18  October  1983]  to  calculate  the  expected  number  of  backorders6  of  the  item 
at  any  point  in  time.  For  this  equation,  the  daily  failure  rate  (ki)  is  calculated  by 
multiplying  the  hourly  failure  rate  of  the  component  (1/MTBF)  by  the  expected  number 
of  operating  hours  per  day,  which  in  this  case  is  24,  thus  X,i  =  24/500  =  0.048.  The  stock 
protection  period  (T)  is  equivalent  to  the  Mean  Requisition  Response  Time  (MRRT); 
current  policy  is  to  set  this  value  equal  to  15  days,  in  accordance  with  supply  system 
requisition  processing  standards.  [NAVSEALOGCEN  October  1995] 


6  In  this  context,  a  backorder  is  a  requisition  that  has  been  referred  off  the  ship  to  be  filled  by  the  wholesale 
supply  system. 
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Assuming  that  demand  is  Poisson  distributed,  the  probability  that  a  given  number 
of  spares  (x)  is  required  during  the  stock  protection  period,  p(x;?ijT),  is  calculated  using 
Equation  3.2.  Utilizing  Equation  3.2,  the  probability  that  a  second  component  is  required 
in  the  15-day  stock  protection  period  is  0.17532.  Summing  the  terms  of  equation  3.1  for 
our  example  yields  an  expected  number  of  backorders  at  any  given  time  of  0.35.  This 
figure  is  then  multiplied  by  2000  (duty  cycle  hours)  to  estimate  the  expected  amount  of 
cumulative  time  the  item  is  on  order  from  the  ship  yielding  a  result  of  700  hours. 


-^T^iTf  (3.2) 


p(x;  A.JT)  =  e"A' "  v  '    7  ,x  =  0,1,2... 


x! 


Since  the  item's  MTBF  is  500  hours,  the  expected  number  of  failures  is  2000/500 
=  4.  The  MSRT  of  the  item  can  then  by  calculated  by  dividing  cumulative  backorder 
time  by  the  number  of  failures.  Since  the  expected  cumulative  amount  of  time  the  item  is 
on  order  from  the  ship  is  700  hours,  the  MSRT  of  the  part  would  be  700/4  =  175  hours. 
If  the  cost  of  additional  unit  of  the  part  was  $500,  the  item  would  be  given  a  score  of 
175/500  =  0.35. 

This  method  is  used  on  every  component  in  the  system  to  calculate  the  value  of 
adding  a  spare  of  that  component  to  the  ship's  allowance  list.  The  component  with  the 
highest  score  is  then  chosen  and  a  spare  for  that  component  is  added  to  the  ship's 
allowance  list.  The  Gross  Effectiveness  (GE)  figure  for  each  equipment  is  then 
calculated  by  dividing  the  sum  of  its  component's  back  orders  (BO  at  any  point  in  time  by 
its  total  number  of  components.  A  more  thorough  description  of  the  ACEV1  methodology 
can  be  found  in  the  ACIM  Handbook.  [CACI  Inc.,  May  1983] 

15 


Though  an  improvement  over  its  demand  based  predecessors,  ACIM  has  three 
major  weaknesses.  First  and  foremost  is  ACIM's  consideration  of  every  system  as  a 
series  of  components,  which  does  not  allow  the  model  to  account  for  the  gain  in 
reliability  caused  by  components  that  are  connected  in  parallel.  The  second  weakness  is 
that  ACIM  assumes  failures  to  occur  as  a  Markov  process.  This  assumption  causes  a 
continuous  failure  process,  which  is  unrealistic,  as  a  failed  component  would  have  to 
spend  some  period  of  time  being  regenerated  prior  to  returning  to  an  operational  status. 
The  final  weakness  is  that  ACIM  is  based  on  steady  state  conditions,  whereas  an  actual 
weapon  system  would  never  reach  steady  state  due  to  its  finite  mission  cycle. 

C.  TIGER  MODEL 

Tiger  is  "a  discrete,  event-driven  model  which  uses  Monte  Carlo  techniques  to 
estimate  system  parameters  given  the  estimated  MTBF  and  MTTR  of  the  system 
components."  [Castillo,  1989]  The  Tiger  program  was  developed  by  NAVSEA  to  assess 
the  reliability,  maintainability  and  availability  of  navy  weapon  systems  and  continues  to 
be  used  to  make  these  evaluations  throughout  the  lifecycle  of  the  weapon  system.  The 
Tiger  simulation  requires  the  following  as  inputs: 

•  Mission  Timeline 

•  System  Equipments 

•  System  Description 

•  Logistic  Support 

The  mission  timeline  is  determined  by  the  program  office  and  is  calculated  with 

respect  to  the  Design  Reference  Mission  (DRM)  of  the  ship  class  on  which  the  weapon 
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system  is  to  be  placed.  "The  DRM  defines  the  distinct  mission  phase  types  (e.g.  in-port, 
cruise,  engagements,  etc..)  that  a  particular  ship  class  is  expected  to  experience  in 
wartime."  [NAVSEALOGCEN,  June  1996]  These  mission  phase  types  are  then  input 
into  Tiger  as  time  sequences,  which  are  used  to  build  the  simulation  timeline. 

The  equipments  of  the  system  are  defined  in  Tiger  by  the  individual  blocks  of  the 
system's  RBD.  Each  block  that  represents  an  equipment  is  given  discrete  reliability 
(MTBF)  and  maintainability  (MTTR)  characteristics  and  the  mission  type  phases  for 
which  it  will  be  operational.  The  system  description  is  made  in  liger  by  linking  these 
blocks  together  and  creating  the  RBD  of  the  system.  As  discussed  in  Chapter  II,  the 
software  utilizes  the  RBD  to  translate  the  structure  of  the  system  to  computer  readable 
code.  This  code  allows  the  simulation  to  determine  the  state  of  the  system  (up  or  down) 
given  a  change  in  any  one  of  its  equipments. 

The  final  input,  logistics  support,  is  provided  by  ACDvI.  Given  a  specified  level 
of  sparing,  ACDVI  utilizes  the  method  discussed  earlier  in  this  chapter  to  calculate  the  GE 
for  each  of  the  system's  equipments.  The  equipment  GE's  are  used  by  Tiger  as  the 
probability  that,  given  a  failure  occurs  that  requires  a  spare  part,  that  part  is  on  the  ship's 
allowance  list  and  is  currently  available  for  issue. 

Once  the  required  information  has  been  input,  the  operator  can  run  the  Tiger 
simulation.  The  simulation  begins  by  scheduling  the  end  of  the  first  phase  of  the  mission 
cycle.  At  this  time  the  system  will  go  through  some  type  of  change  in  the  equipments 
that  are  required  to  maintain  the  system  in  an  operational  status  for  that  mission  cycle.  A 
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failure  event  is  then  scheduled  for  each  of  the  equipments  required  by  the  first  phase. 
After  these  events  have  been  scheduled,  the  mission  cycle  begins  with  all  equipments  in 
an  "up"  status.  As  equipment  failures  occur,  repairs  are  made  by  first  determining  the 
logistics  response  time  and  then  the  time  to  repair.  Drawing  a  random  number  between  0 
and  1  determines  the  logistics  response  time;  if  the  number  is  less  than  the  GE  for  that 
equipment,  the  shipboard  logistics  delay  of  2  hours  is  used.  Otherwise,  a  logistics  delay 
of  360  hours  is  used*  Once  the  logistics  delay  transpires,  the  time  to  repair  is  calculated 
by  sampling  from  a  \  exponential  distribution  with  a  mean  equal  to  the  MTTR  of  the 
equipment.  After  this  time  has  elapsed,  the  equipment  is  scheduled  to  fail  once  again  and 
is  "turned  on."  This  process  continues  throughout  the  mission  cycle  for  those 
equipments  required  by  the  current  phase.  Once  the  mission  cycle  is  complete  the 
program  is  reset  and  iun  again,  continuing  in  this  manner  until  it  reaches  the  number  of 
iterations  predetermined  by  the  user.  After  all  iterations  are  complete,  Tiger  computes 
system  availability  by  dividing  total  system  uptime  over  all  trials  by  total  time  for  all 
trials. 

The  major  weakness  of  the  Tiger  model  involves  the  number  of  iterations  the 
model  is  run,  there  is  no  set  policy  for  the  user  to  determine  this  number.  Current 
practice  is  for  the  user  to  estimate  the  number,  run  the  model,  then  choose  a  higher 
number  and  run  the  model  again.  The  user  then  compares  the  two  results  and  determines 


7  The  time  of  the  failure  events  are  determined  by  sampling  from  an  exponential  distribution  with  a  mean 
equal  to  the  MTBF  of  the  equipment. 

8  The  logistics  delays  of  2  hours  and  360  hours  reflect  goals  the  Navy  has  set  for  shipboard  and  wholesale 
supply  response. 
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if  the  estimation  of  system  availability  has  converged.   This  method  provides  no  control 
for  accuracy  and  no  measure  of  the  standard  error  of  the  results. 

D.  OPT  PROGRAM 

The  OPT  program  was  developed  by  NAVSUP  to  integrate  the  use  of  Tiger  and 
ACIM  in  the  RBS  workstation.  The  process  begins  by  performing  a  set  of  Tiger  runs  for 
each  of  the  individual  equipments  that  make  up  the  system.  These  runs  are  done  to  find 
the  equipment  Ao  over  the  following  range  of  GE  figures:  0.0,  0.5.  0.75,  0.9  and  1.0.  A 
cubic  spline  is  then  used  to  fit  a  curve  through  these  points,  which  is  called  the  selection 
curve  for  that  equipment.  The  selection  curves  for  a  notional  system  consisting  of  two 
equipments  (A  and  Bj  are  depicted  in  figure  3.1. 
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In  the  next  step  of  the  process,  ACIM  is  used  to  determine  the  order  that  spare 
parts  will  be  added  to  the  ship's  allowance  list.  Utilizing  the  method  discussed  earlier  in 
this  chapter,  ACIM  considers  each  equipment  independently,  ranking  its  components  in 
accordance  with  their  individual  contribution  to  equipment  GE  per  dollar  spent.  The 
result  being  the  creation  of  what  is  called  the  sparing  index  for  that  equipment.  Table  3.1 
is  an  example  of  a  sparing  index  that  would  correspond  to  Figure  3.1.  From  this  table, 
the  addition  of  part  number  2222A  would  increase  equipment  A's  GE  from  .205  to  .396. 


Equipment  A 

Equipment  B 

Component 

GE 

Component 

GE 

1111A 

.205 

HUB 

.425 

2222A 

.396 

2222B 

.585 

3333A 

.485 

3333B 

.695 

Table  3.1  Equipment  Sparing  Indices 

Once  the  selection  curves  and  sparing  indices  have  been  developed,  an  iterative 
process  begins.  For  the  first  step,  only  the  highest-ranking  component  on  each  sparing 
index  is  considered.  The  improvement  that  these  components  makes  to  their  parent 
equipment's  Ao  is  then  computed,  the  one  resulting  in  the  greatest  improvement  is  then 
added  to  the  shipboard  allowance  list.  For  example,  using  the  data  from  Table  3.1,  the 
addition  of  part  1 1 1 1A  improves  equipment  A's  GE  to  .205,  which  corresponds  to  an  Ao 
increase  of  0. 1  (0.6  to  0.7).   The  addition  of  component  1 1 1  IB  improves  equipment  B's 
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GE  to  .425,  which  corresponds  to  an  Ao  increase  of  0. 15.  This  can  be  seen  graphically  in 
Figure  3.2. 
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Figure  3.2  Component  Comparison  on  Equipment  Selection 

Curves 


From  our  example,  component  1 1 1  IB  would  be  chosen  as  it  yields  the  greatest 
improvement  in  equipment  Ao.  The  next  step  is  to  use  Tiger  to  calculate  the  system  Ao 
given  that  component  1 1 1  IB  is  allowed  onboard.  If  the  system's  Ao  goal  is  not  met,  the 
equipment  Ao  improvement  from  the  next  ranking  component  on  equipment  B's  sparing 
index  (2222B  in  our  example)  would  be  compared  to  the  improvement  for  equipment  A 
that  was  found  in  the  previous  comparison.  The  process  continues  until  the  calculated  Ao 
of  the  system  becomes  asymptotic  to  the  system's  inherent  availability. 
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E.  RBS  WORKSTATION 

The  RBS  workstation  is  the  operating  environment  created  by  the  NAVSUP  to 
give  program  offices  a  user-friendly  environment  to  determine  sparing  levels  for  their 
weapon  systems.  The  RBS  workstation  is  a  DOS-based  software  package  that  can  be  run 
on  any  PC.  The  AC1M  and  OPT  programs  are  run  from  the  retail  allowance  menu  while 
Tiger  is  run  from  the  readiness  menu,  as  shown  in  Figures  3.3  and  3  4. 


Figure  3.3  Retail  Allowance  Menu 
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Figure  3.4  Readiness  Menu 


The  RBS  workstation  also  comes  with  a  utility  called  the  Computer  Aided 
Readiness  Assessment  Tool  (CARAT).  CARAT  is  a  Graphical  User  Interface  (GUI)  that 
allows  the  user  to  develop  RBD's  and  their  corresponding  Tiger  and  ACBVI  input  files, 
the  CARAT  user  environment  is  depicted  in  Figure  3.5.  All  NAVSEA/SPAWAR 
programs  that  require  RBS  sparing  levels  currently  use  the  RBS  workstation. 
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Figure  3.5  CARAT  User  Environment 
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IV.       BATTLEGROUP  SPARING  SIMULATION  MODEL  (BSSM) 

A.  OVERVIEW 

The  Battlegroup  Sparing  Simulation  Model  (BSSM)  is  an  object-oriented 
computer  simulation  written  in  MODSIM.  It  is  a  discrete-event  model  that  simulates 
weapon  system  failures  at  the  component  level.  The  structure  of  the  weapon  system 
under  consideration  is  input  into  BSSM  utilizing  its  RBD.  The  RBD  breaks  the  system 
down  into  a  series  of  blocks  that  represent  its  equipments.  These  equipment  blocks  are 
then  broken  down  further  until  the  system  is  represented  by  its  individual  components, 
connected  through  both  series  and  parallel  relationships.  These  relationships  allow  the 
model  to  determine  the  state  of  the  blocks  and  ultimately  the  state  of  the  system  at  any 
time  during  the  simulation. 

B.  SIMULATION  OBJECTS 

BSSM  uses  five  types  of  objects  to  simulate  failures,  determine  the  impacts  of 
those  failures  and  keep  track  of  readiness  statistics.  These  objects  act  independently  and 
can  represent  a  battlegroup,  a  ship,  a  weapon  system,  a  block  or  a  component 

1.    The  Block  Object 

The  block  object  is  the  basic  unit  which  allows  the  simulation  to  maintain  the 
structure  of  the  system.  At  any  given  time  the  state  of  the  system  can  be  evaluated  by  the 
state  of  its  subordinate  blocks.  A  block  can  have  only  one  parent,  which  must  also  be  a 
block,  but  can  have  any  number  of  sub-blocks  and  or  components  that  are  subordinate  to 
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it.  There  are  three  different  state  spaces  in  which  a  block  may  reside  in  at  any  point  in 
time,  it  can  be: 

•  "on"  and  "operational"  where  the  block  is  functional  and  operating  at  that  point  in 
time. 

•  "off'  and  "operational"  where  the  block  is  functional  but  not  operating  at  that 
point  in  time 

•  "off'  and  "not-operational"  where  the  block  is  not  functional  and  thus  is  not 
operating  at  that  point  in  time. 

The  required  number  of  subordinates  for  each  block  to  remain  operational  is  stored  one  of 
the  block's  fields,  and  is  set  when  the  block  is  initiated.  This  field  allows  the  block  to 
determine  its  operational  state  at  any  time  by  counting  the  number  of  subordinates  that 
are  operational  at  that  time.  If  there  is  a  change  in  the  state  of  one  of  its  subordinates, 
that  subordinate  will  notify  the  block,  triggering  it  to  re-determine  its  operational  status 
and  take  appropriate  action. 

2.    The  Component  Object 

A  component  object  models  the  basic  components  that  make*  up  the  system.  The 
component  object  inherits  the  functions  and  methods  of  the  block  object  with  the 
exception  of  the  metnods  that  schedule  failures  and  turn  the  components  on  and  off.  The 
component  object  also  has  fields  to  store  additional  information.  These  fields  allow  the 
model  to  determine  the  component's  remaining  lifetime,  the  maintenance  capability 
required  to  repair  the  it  and  the  length  of  time  that  repair  will  take.  Table  4.1  is  a 
summary  of  these  fields. 
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Field 

Description 

Purpose 

Lifelength 

Remaining  life  of  the 
component  (Real) 

Component  failure  is  triggered  when  life- 
length  expires. 

StockNo 

Part  number  of  the 
component  (Integer) 

Allows  the  model  to  determine  stock 
availability  of  the  failed  item. 

Capability 

Ship  repair  capability. 
(Boolean) 

Allows  the  model  to  determine  whether  or 
not  the  repair  can  be  made  while  at  sea. 

RepairTime 

MTTR  of  the  component. 
(Real) 

Allows  the  model  to  determine  the  time  to 
repair  when  the  spare  becomes  available. 

TimeToFail 

Failure  rate  of  the 
component  (Real) 

Allows  the  model  to  determine  the  life-length 
of  an  iteration  of  that  component. 

Table  4.1  Additional  Component  Fields 

3.  The  System  Object 

The  system  object  inherits  the  functions  and  methods  of  the  block  object.  It 
creates  the  blocks  and  components  that  make  up  the  system  when  it  is  initiated  and  keeps 
track  of  a  ship  object  as  its  parent.  The  system  object  generates  the  remaining  lifetimes 
of  the  components  in  the  system  and  regenerates  failed  components  after  their  associated 
logistics  delay  has  expired.  Finally,  the  system  object  keeps  track  of  the  time  it  is 
operational  and  not  operational  to  be  used  in  the  final  Ao  calculation  for  the  mission 
cycle. 

4.  The  Ship  Object 

The  ship  can  contain  any  number  of  subordinate  system  objects.   The  ship  object 
performs  three  basic  tasks  for  the  simulation: 
•     Maintains  the  shipboard  level  inventory. 
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• 


• 


Provides  its  system  objects  with  the  appropriate  logistics  delay  when  a  failure 

occurs. 

Turns  its  system  objects  off  and  on  as  the  ship  pulls  in  and  out  of  port. 

Allows   for   the   flexibility   to   create   multi-system   structures,    capturing   the 

interaction  between  systems  with  common  spares,  estimating  the  overall  readiness 

of  a  ship. 

5.    The  Battlegroup  Object 

The  battlegroup  object  can  hold  any  given  number  of  ships  and  is  similar  to  the 
ship  object  in  that  it  has  its  own  level  of  inventory.  The  battlegroup  object  is  the  final 
clearinghouse  for  all  requisitions  that  cannot  be  satisfied  onboard  a  ship  object.  When 
this  occurs  the  battlegroup  screens  its  stock  and  provides  the  system  object  the 
appropriate  logistics  delay.  If  the  requisition  can  be  filled  by  a  part  from  the  battlegroup 
inventory,  a  delay  of  48  hours9  will  be  returned.  Otherwise  a  delay  of  360  hours  will  be 
returned  reflecting  a  requisition  that  has  been  referred  to  the  wholesale  supply  system. 
The  battlegroup  object  controls  the  simulation,  looping  the  ships  through  the  given 
mission  cycle  and  stopping  the  simulation  when  the  desired  level  of  confidence  has  been 
obtained. 
C.  THE  SIMULATION 

Prior  to  running  the  simulation,  the  RBD  of  the  system  under  consideration  must 
be  reviewed  to  determine  how  the  actual  structural  relationship  of  the  system  relates  to 
the  block  and  component  structure  of  the  model.  A  data  file  is  then  created  in  accordance 


9  The  48-hour  delay  for  requisitions  that  are  in  stock  at  the  battlegroup  level  is  an  estimate  of  the  amount  of 
time  required  to  transport  the  required  part  to  the  requisitioning  unit. 
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with  Appendix  B.    The  simple  RBD  depicted  in  Figure  4.1  will  be  the  example  used  in 
further  discussion  of  the  model. 
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Figure  4.1  Sample  Reliability  Block  Diagram 

As  the  model  reads  the  data  file  it  creates  the  block  and  component  objects  that 
make  up  the  system,  setting  the  appropriate  fields  to  their  initial  values.  After  each 
component  is  created  it  also  calculates  the  remaining  lifetime  of  the  component  in 
accordance  with  its  MTBF.  Once  the  structure  is  input,  the  simulation  is  started  from 
within  the  battlegroup  object.  A  recursive  function  is  then  activated,  turning  on  the  ships, 
their  systems  and  ultimately  the  blocks  and  components  that  make  up  these  systems.  As 
the  components  are  turned  on,  they  will  schedule  failure  events  in  accordance  with  their 
remaining  lifetime.  The  simulation  continues  to  run  for  the  length  of  the  system's 
mission  cycle. 
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A  failure  event  occurs  when  the  remaining  lifetime  of  a  component  expires.  This 
event  causes  the  component  to  turn  itself  off,  put  itself  in  a  non-operational  state  and 
notify  its  parent  that  it  has  failed.  The  parent  block  then  determines  its  operational  status 
based  on  the  system's  RBD.  If  the  component  failure  results  in  the  failure  of  the  entire 
block,  the  block  turns  itself  off,  puts  itself  in  a  non-operational  status  and  notifies  its 
parent.  This  process  continues  up  the  block  structure  of  the  system  until  either  the  entire 
system  fails  or  a  block  does  not  fail  due  to  the  failure  of  one  of  its  subordinates. 

For  example,  in  Figure  4.1,  if  component  Dl  were  the  first  to  fail,  it  would  put 
itself  in  a  non-operational  state,  then  notify  block  D  that  it  had  failed10.  Block  D  would 
then  see  that  component  D2  is  still  operational  and  therefore  conclude  that  it  was  still 
operational.  Thus  the  process  would  end  at  block  D  and  no  further  action  would  be  taken 
due  to  the  failure  of  Dl.  However,  if  component  D2  were  to  fail  prior  to  the  repair  of 
component  Dl,  block  D  would  conclude  that  it  was  not  operational,  place  itself  in  a  non- 
operational  status  and  notify  the  system  of  its  failure.  Since  block  D  is  in  the  critical  path 
of  operation  for  the  system,  the  system  would  then  be  forced  to  turn  itself  off. 

Another  action  that  is  initiated  when  a  component  fails  is  the  regeneration  of  the 
failed  component.  The  process  begins  with  the  component  notifying  the  system  that  it 
has  failed.  The  system  then  determines  if  ship's  force  is  capable  of  completing  the  repair, 
and  if  so  it  requests  a  spare  from  its  ship.  The  ship  will  then  check  to  see  if  a  spare  is 
available  to  replenish  the  required  component.  If  it  is,  it  provides  the  system  with  a 
shipboard  logistics  delay  time  of  2  hours,  otherwise  it  refers  the  requirement  to  the 
battlegroup,  which  will  check  its  inventory  and  provide  the  appropriate  delay.     After 


10  This  simulation  assumes  system  diagnostics  capable  of  detecting  failures  in  parallel  components. 
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waiting  the  appropriate  delay  time  the  system  calculates  the  repair  time  of  the  component 
using  its  MTTR;  once  this  time  has  passed  it  regenerates  the  component. 

If  ship's  force  is  not  capable  of  completing  the  repair,  the  system  waits  until  the 
ship  pulls  into  port,  then  it  calculates  and  waits  the  appropriate  repair  time,  regenerating 
the  component  after  this  time  has  passed. 

Once  regenerated,  the  component  will  change  its  state  to  operational  and  notify 
the  block  above  it.  If  the  parent  block  was  previously  non-operational,  the  component's 
regeneration  will  trigger  the  block  to  check  its  operational  status.  If  the  block  is  now 
operational  it  will  change  its  state  and  notify  its  parent.  This  process  continues  up  the 
structure  of  the  system  until  either  a  block  is  reached  that  was  previously  operational  or 
the  system  changes  its  state  to  operational.  When  the  process  reaches  a  block  that  was 
previously  operational,  the  subordinate  will  check  to  see  if  its  parent  is  also  operational. 
If  so  it  will  turn  itself  on  and  start  a  recursive  process  that  will  turn  on  all  of  its 
subordinate  blocks  and  components.  Using  the  previous  example,  when  component  Dl 
was  regenerated  it  would  notify  block  D.  Assuming  block  D  was  in  an  operational  and 
operating  status  it  would  turn  component  Dl  on  and  the  process  would  be  complete.  This 
process  continues  throughout  the  mission  cycle  of  the  system,  during  which  time  each 
block  (including  the  system  itself)  keeps  track  of  its  uptime  and  downtime.  These  figures 
allow  the  system  to  calculate  its  availability  at  the  end  of  each  mission  cycle.  The  result 
is  then  placed  in  a  statistical  object  to  determine  the  average  system  availability.  The 
statistical  object  also  calculates  a  95%  confidence  interval  based  on  the  normal 
distribution. 
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D.  MODEL  VALIDATION 

The  battlegroup  simulation  model  was  validated  in  two  stages.  The  first  stage 
consisted  of  a  series  of  BSSM  runs  for  a  small  system  whose  readiness  could  be  manually 
calculated.  For  the  second  stage,  a  comparison  was  made  between  budget  to  readiness 
curves  created  for  the  CES  using  Tiger  and  BSSM. 


Figure  4.2  BSSM  Validation  System 


The  first  stag-  began  with  the  development  of  the  small  system  shown  in  figure 
(4.2)  consisting  of  three  blocks  (1,2  and  3)  on  the  reliability  line.  Blocks  1  and  2  consist 
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of  only  one  component,  while  block  3  has  two  sub-blocks  (31  and  32).  Block  31  consists 
of  two  components  (311  and  312)  which  are  connected  in  parallel  while  block  32  consists 
of  two  components  (321  and  322)  which  are  connected  in  series.  A  data  set  was  then 
built  for  the  system  in  accordance  with  Appendix  (B)  and  loaded  into  the  BSSM.  The 
BSSM  was  then  modified  to  run  with  output  statements  showing  the  time  of  each 
component  failure  and  regeneration.  The  model  was  then  run  and  the  figures  produced 
were  used  to  calculc^e  system  readiness  manually.  A  comparison  was  then  made  between 
manual  calculation  and  the  readiness  figures  produced  by  the  model.  As  the  two  figures 
matched  exactly,  the  first  stage  of  the  validation  was  considered  to  be  complete.  For  the 
second  stage  of  the  validation,  a  budget-to-readiness  curve  was  created  for  CES.  The 
curve  was  produced  by  plotting  the  points  from  an  OPT  listing  created  by 
NAVSEALOGCEN  using  the  RBS  methodology  discussed  in  Chapter  HI.  The  BSSM 
was  then  used  to  produce  a  similar  curve,  the  two  curves  are  shown  in  Figure  (4.3).  The 
points  of  the  RBS  OPT  are  depicted  as  squares  while  the  points  of  the  BSSM  OPT  are 
depicted  as  circles.  As  both  of  these  models  are  simulations  it  is  understood  that  the 
results  would  not  match  exactly,  however,  since  both  models  produced  similar  results 
throughout  the  spectrum  of  the  OPT  listing,  the  BSSM  was  considered  to  be  an  accurate 
measure  of  system  readiness  for  a  given  level  of  sparing. 
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Figure  4.3  RBS  vs.  BSSM  Single  Ship  Budget  to  Readiness  Curves 
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V.         APPLICATION  OF  BSSM  TO  CES 

A.  METHODOLOGY 

In  the  previous  chapter,  BSSM  was  used  to  create  a  single  ship  budget-to- 
readiness  curve.  To  be  consistent  in  the  comparison  of  the  battlegroup  and  single-ship 
inventory  strategies,  this  curve  will  serve  as  the  baseline,  representing  the  single-ship 
sparing  method  in  practice  today.  The  BSSM  OPT  list  for  a  single-ship  strategy  is 
included  as  Appendix  (C),  reflecting  the  level  of  sparing  required  to  achieve  95%  Ao.11 

A  data  set  for  a  battlegroup  of  10  identical  ships  was  then  created  to  be  the  input 
model  for  a  series  of  runs  of  the  BSSM  model.  For  the  initial  run,  the  battlegroup  level  of 
inventory  had  no  spares,  while  each  of  the  10  ships  carried  a  full  complement  of  the 
spares  required  achieve  95%  Ao.  For  each  subsequent  run,  the  lowest  ranking  (in 
accordance  with  Appendix  (C))  remaining  spare  part  at  the  shipboard  level  was  removed 
from  each  ship  and  a  single  unit  of  this  spare  was  placed  at  the  battlegroup  level.  For 
example,  in  the  second  iteration,  part  number  7019023  was  removed  from  each  of  the  10 
ships  and  a  single  unit  of  part  number  7019023  was  placed  at  the  battlegroup  level.  This 
process  continued  throughout  the  spectrum  of  Appendix  (C),  the  result  being  the  creation 
of  a  battlegroup  OPT  listing  that  is  included  as  Appendix  (D).  These  data  were  used  to 
create  a  Battlegroup  Budget  to  Readiness  curve,  which  is  shown  with  the  single  ship 
budget  to  readiness  curve  in  Figure  5.1.  In  this  Figure,  the  battlegroxp-sparing  budget-to- 
readiness  curve  is  depicted  by  squares  while  circles  depict  the  single-ship  curve. 


11  The  Mission  Need  Statement  (MNS)  of  CES  requires  95%  system  availability. 
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B.  ANALYSIS 

Since  a  simulation  produced  the  points  in  Figure  5.1,  they  are  only  estimates  of 
what  the  actual  readiness  would  be  for  that  level  of  sparing12.  To  combine  these  points 
into  a  more  precise  estimate  of  the  budget  and  readiness  impacts  of  each  inventory 
strategy,  regression  analysis  was  performed  on  each  set  of  points. 

A  system's  Ao  is  limited  by  100%  readiness.  Readiness  should  also 
monotonically  increase  as  the  spares  budget  increases,  making  the  budget-to-readiness 
curve  act  a  lot  like  a  Cumulative  Density  Function  (CDF).   The  Logistics  CDF  is  shaped 


12  Using  one  thousand  iterations,  the  average  variability  of  the  BSSM  estimate  was  plus  or  minus  .003. 
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in  a  manner  similar  to  that  of  both  data  sets,  making  it  a  natural  candidate  to  fit  the  data. 
Equation  5.1  is  the  basic  form  of  the  Logistics  CDF,  while  Equation  5.2  is  the  form  used 
to  fit  the  data.  It  should  be  noted  that  (a)  is  the  intercept  of  the  curve  on  the  Ao  axis  and 
should  equate  to  the  system's  Az  while  (b)  is  the  maximum  increase  in  system  Ao,  thus 
(a  +  b)  should  equate  to  the  system's  Ai. 


y=a+l  +  e(-(I-d)*c,  <«) 


Utilizing  SPLUS  software  and  a  function  created  by  Professor  Sam  Butterey  of 
the  Naval  Postgraduate  School,  the  data  was  fit  the  form  of  Equation  5.2.  The  results  of 
this  function  were  Equations  5.3  and  5.4,  which  fit  the  single  ship  and  battlegroup  sets  of 
data  respectively.  The  variable  x  in  these  Equations  is  equivalent  to  the  cost  of  each 
inventory  strategy.  Figure  5.2  is  a  graphical  depiction  of  these  curves  with  their 
respective  data  sets. 


Ao  =  .696  +  - '?**       1ft«  (5-3) 

J  +  e-(log(x)-11.0)*1.06 


•267 

Ao  =  .69  + .,    ,  ,  1ft^,ft#t  <5-4) 

I  +  e-0og(*)- 10.7)*  2.06 
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Figure  5.2  Battlegroup  and  Single-Ship  Data  with  Fitted  Curves 


Having  fit  the  two  data  sets  to  Equations  5.3  and  5.4,  it  is  simple  to  compare  the 

impacts  of  the  two  inventory  strategies.      Solving  each  of  them  for  the  95%  Ao 

requirement  yielded  budget  requirements  of  $463,804.70  for  the  single  ship  strategy  and 

$256,472.40  for  the  battlegroup  strategy,  an  inventory  savings  of  nearly  50%  per  ship. 

Multiplying  this  cost  savings  of    $207,332.30  per  ship  over  the  expected  number  of 

installs,  146  in  this  case,  [Mr.  Jeff  Hoare,  13  August  1997]  indicates  that  a  total  cost 

savings  of  over  $30  million  could  be  achieved  utilizing  the  battlegroup  sparing  inventory 

strategy. 
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This,  however,  is  only  one  of  many  possible  inventory  strategies  that  could 
achieve  95%  Ao.  Increasing  the  range  and  depth  of  the  battlegroup  inventory  would 
reduce  the  inventory  requirement  for  the  individual  ships,  but  it  isn't  clear  how  far  should 
this  be  taken.  Ideally,  there  should  be  some  policy  for  determining  the  level  of  sparing 
each  ship  must  have.  Given  this  policy,  the  battlegroup  inventory  could  be  modified  to 
meet  the  system  Ao  requirement. 
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Figure  5.3  Marginal  Increase  to  System  Readiness 

For  example,  taking  the  derivative  of  Equation  5.3  yields  the  marginal  increase  to 
readiness  of  each  additional  dollar  spent  on  the  shipboard  inventory.  Figure  5.3  shows 
this  derivative  throughout  the  relative  budget  range.    If  shipboard  sparing  was  stopped 
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when  the  marginal  increase  in  system  readiness  per  $100,000  fell  below  .00513,  the  per 
ship  sparing  budget  would  be  reduced  to  a  little  over  $100,0OC.  The  battlegroup 
inventory  could  then  be  augmented  in  order  of  the  system's  OPT  list  until  the  system 
reached  95%  Ao.  In  the  case  of  CES,  this  policy  resulted  in  a  shipboard  inventory  valued 
at  $121,162  and  a  battlegroup  inventory  valued  at  $526,641,  yielding  a  total  cost  of 
$177,803  per  ship,  a  savings  of  over  $286,000  from  the  original  single  ship  strategy.  The 
recommended  battlegroup  and  shipboard  level  inventory  lists  are  included  as  Appendix 
(E). 

C.  VARYING  BATTLEGROUP  SIZE 

The  final  point  of  interest  in  the  battlegroup-sparing  question  is  the  rate  at  which 
an  increase  in  the  size  of  a  battlegroup  would  reduce  the  effectiveness  of  the  strategy.  As 
the  fleet  commander  may  want  to  deploy  more  than  10  ships  to  a  geographic  area,  he/she 
would  need  to  know  the  readiness  impacts  of  additional  ships  competing  for  the 
battlegroup  spares.  The  BSSM  was  used  to  provide  an  answer  for  this  question.  Using 
the  inventory  levels  from  Appendix  (E),  additional  runs  of  the  BSSM  were  conducted, 
varying  the  number  of  ships  in  the  battlegroup  from  5  to  40.  The  resulting  readiness 
estimates  are  shown  in  Figure  5.4.  As  these  points  appeared  to  have  a  linear  relationship, 
a  linear  regression  was  performed  and  included  in  the  figure.  As  expected,  system 
readiness  decreased  with  an  increase  in  battlegroup  size.  However  this  decrease  in 
readiness  occurred  at  a  rate  of  only  .03%  per  ship,  proving  battlegroup  sparing  to  be  not 
only  a  low  cost  sparing  alternative,  but  a  flexible  one  as  well. 


13  This  value  was  set  arbitrarily  by  the  author  as  an  example  of  the  proposed  policy  change. 
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Figure  5.4  Effect  of  Varying  Battlegroup  Size  on  System  Readiness 
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VI.       DISCUSSION/RECOMMENDATIONS 

In  summary,  this  thesis  has  accomplished  three  separate  tasks.  First,  it  has 
uncovered  weaknesses  in  the  RBS  techniques  currently  used  by  the  U.S.  Navy.  Second, 
it  developed  a  model  to  evaluate  the  impacts  of  battlegroup  sparing.  Finally,  it  used  this 
model  to  show  that  battlegroup  sparing  is  an  inventory  option  that,  for  some  weapon 
systems,  can  achieve  a  desired  level  of  system  readiness  at  a  greatly  reduced  inventory 
cost. 

It  should  be  noted  that  this  inventory  strategy  is  not  suited  for  all  shipboard 
weapon  systems.  The  cost  of  obtaining  RBS  data  for  the  Navy's  older  systems  and  the 
variation  in  configuration  from  platform  to  platform  of  other  systems  do  not  lend 
themselves  to  this  type  of  inventory  strategy.  The  cost  of  creating  this  data  and  the  fact 
that  shipboard  spares  have  already  been  procured  for  these  systems  minimizes  the  real 
savings  that  could  by  achieved  by  utilizing  this  strategy.  There  are  however,  a  large 
number  of  systems  that  meet  the  criteria  discussed  in  Chapter  I  of  this  thesis. 

A.  WEAKNESSES  OF  RBS  UNCOVERED 

Over  the  course  of  the  RBS  discussion  in  this  thesis,  several  weaknesses  were 
uncovered  involving  the  current  process.  The  weaknesses  found  concerning  ACIM  were: 

1 .  Components  are  considered  to  be  connected  in  series. 

2.  Calculations  are  based  on  steady-state  conditions. 

3.  Failures  occur  as  a  Markov  Process. 

The  first  two  weaknesses  are  challenging  problems  and  ACIM  may  be  the  closest  we  can 

get  to  a  closed  form  solution.    Future  studies  should  attempt  to  measure  the  impact  of 
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these  assumptions  to  determine  the  necessity  of  pursuing  these  questions  further.  The 
third  weakness,  however,  could  be  corrected  by  considering  the  failures  of  components  to 
be  an  Alternating  Renewal  Process  (ARP).  Utilizing  an  ARP  instead  of  the  current 
Markov  Process  would  allow  the  model  to  account  for  the  component  downtime  that  is 
involved  in  every  failure. 

The  weakness  noted  concerning  Tiger  involved  the  manner  in  which  stopping 
conditions  were  set  A  change  in  the  method  in  which  Tiger  keeps  its  system  availability 
statistic  would  provide  a  good  solution  to  this  problem.  The  statistic  should  be  changed 
so  that  system  availability  is  calculated  at  each  iteration  of  the  model.  These  figures 
could  then  be  used  not  only  to  determine  overall  system  availability  but  also  a  standard 
error  of  the  estimate.  Tiger  could  then  be  modified  to  stop  running  once  the  standard 
error  was  within  some  predetermined  tolerance  level.  This  method  would  provide  the 
user  with  a  consistent  level  of  accuracy  and  minimize  excessive  Tiger  runs  on  a  given  set 
of  data 

B.  FLEET  IMPLEMENTATION 

Upon  measuring  the  impacts  of  the  battlegroup  sparing,  it  becomes  necessary  to 
develop  a  plan  to  successfully  implement  the  strategy.  This  critical  link  to  the  successful 
implementation  of  battlegroup  sparing  is  an  understanding  between  a  system's  program 
office  and  the  type  commanders  who  will  be  deploying  this  system.  The  type 
commander  would  need  to  agree  to  allow  the  program  office  to  outfit  its  ships  to  some 
level  below  the  specified  Ao  goal.  In  return,  the  program  office  would  provide  the  type 
commander  with  battlegroup  level  pack-up  kits  that  would  allow  the  type  commanders  to 
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utilize  battlegroup  sparing  to  meet  the  system's  Ao  goal.  In  the  case  of  CES,  the  type 
commander  must  agree  to  accept  the  program  office  providing  initial  spares  funding  to  its 
ships  that  would  only  achieve  93%  shipboard  Ao.  In  return,  the  program  office  can 
provide  the  type  commander  the  initial  spares  to  set  up  pack-up  kits  that  will  increase  the 
Ao  of  deployed  CES  units  to  95%. 

C.  TOPICS  FOR  F  URTHER  STUDY 

This  thesis  has  developed,  validated  and  utilized  the  BSSM  model  to  better 
understand  the  relationship  between  cost  and  readiness  when  a  battlegroup  sparing 
inventory  strategy  is  used.  It  has  also  raised  questions  concerning  the  RBS  methodology 
currently  in  use  that  should  be  addressed  in  further  studies.  Possible  topics  for  further 
study  include  the  following: 

1 .  Determining  the  impacts  of  using  an  Alternating  Renewal  Process  versus  a  Markov 
Process  to  calculate  the  expected  number  of  demands  in  ACIM. 

2.  Studying  the  impacts  of  modifying  the  statistics  used  in  Tiger  to  change  the  stopping 
criteria  of  the  model. 

Though  not  included  in  this  thesis,  the  BSSM  model  is  available  for  any  further  studies  in 
this  area  and  will  be  provided  on  request  from  the  author. 
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APPENDIX  A:  COOPERATIVE  ENGAGEMENT  SYSTEM  (CES) 
RELIABILITY  BLOCK  DIAGRAM  (RBD) 

NOMENCLATURE:  AN/USG-2  CEC  VER  F 
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APPENDIX  B;  Battlegroup  Sparing  Simulation  Model  Users  Guide 

The  Battlegroup  Sparing  Simulation  Model  (BSSM)  is  an  object-oriented 
computer  simulation  written  in  MODSIM.  The  model  is  estimates  the  expected  readiness 
of  multiple  weapon  systems  in  a  multiple  ship  environment  using  a  multi-echelon 
inventory  strategy.  The  model  requires  a  battlegroup  timeline,  shipboard  and  battlegroup 
inventory  lists  and  a  main  input  file  which  creates  the  ships  and  weapon  systems  in  the 
battlegroup. 

A.  BATTLEGROUP  TIMELINE 

The  mission  requirements  of  a  ship's  systems  change  as  the  ship  moves  from  an  at 
sea  period  to  an  in  port  period.  The  battlegroup  timeline  file  inputs  these  times  into  the 
battlegroup  object  to  allow  it  determine  the  time  for  its  ships  to  make  these  changes 
during  the  deployment  cycle.  As  a  ship  moves  from  an  at  sea  period  to  an  in  port  period, 
or  vice  versa,  the  ship  changes  the  requirements  placed  on  its  system's  to  be  considered 
in  an  "up"  status. 

The  initial  entry  of  the  file  is  the  total  number  of  mission  cycle  changes  that  will 
take  place  in  the  deployment  cycle.  The  remainder  of  the  file  consists  of  a  column 
representing  the  times  the  ships  are  to  be  at  sea  and  a  column  for  the  times  the  ships  will 
be  in  port.  All  entries  are  in  hours  and  must  be  integers.  The  file  should  be  named 
timeline.txt  and  placed  in  the  same  directory  as  the  main  BSSM  program. 

B.  BATTLEGROUP/SHIP  INVENTORY 

The  battlegroup  and  ship  inventory  files  are  listings  of  the  spare  parts  that  are  held 
at  the  battlegroup  and  shipboard  levels  of  inventory.   The  initial  entry  of  each  file  is  the 
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total  number  of  parts  that  will  be  in  that  inventory.  Following  the  initial  entry,  the 
remainder  of  the  file  is  separated  into  two  columns.  The  first  column  is  a  listing  of  part 
numbers;  these  must  be  alphanumeric  values.  The  second  column  is  the  allowance 
quantities  that  correspond  to  the  part  numbers  in  the  first  column;  all  values  must  be 
integers.  These  files  should  be  named  battle.txt  and  ship.txt  respectively  and  placed  in 
the  same  directory  as  the  main  BSSM  program. 
C.  MAIN  INPUT  FILE 

The  main  input  file  creates  the  ships  and  their  systems,  which  are  being  simulated. 
This  file  is  separated  into  three  sections.  The  first  section  builds  the  battlegroup,  the 
second  builds  the  ships  and  the  third  builds  the  weapon  systems.  The  system  depicted  in 
Figure  B-2  will  be  used  to  demonstrate  this  process. 

The  battlegroup  section  consists  of  the  number  of  ships  in  the  battlegroup,  the 
battlegroup  logistics  delay  time,  the  wholesale  logistics  time  and  the  battlegroup  stock 
replenishment  time.  All  entries  in  the  battlegroup  section  must  be  integers.  Assuming 
the  battlegroup  consists  of  three  ships  and  the  logistics  delays  discussed  in  this  thesis,  the 
first  entries  of  the  input  file  are  3,  48,  360,  and  720. 

The  next  section  builds  the  ships  within  the  battlegroup.  It  consists  of  the  number 
of  systems  on  each  ship,  the  shipboard  logistics  delay  time  and  the  shipboard  stock 
replenishment  time    All  entries  in  the  battlegroup  and  ship  sections  must  be  integers. 
Assuming  we  are  modeling  one  weapon  system  per  ship  the  next  entries  in  the  input  file 
are  1,2,  and  720. 
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Figure  B-l  System  Example 

The  third  and  final  section  builds  the  system.  It  begins  by  building  a  system 
object.  The  system  object  then  creates  its  equipment  blocks,  which  continue  to  create 
their  subordinate  blocks  and  components  as  they  are  created.  The  process  begins  with  the 
creation  of  the  system. 

The  system  is  a  block  itself  and  thus  uses  the  same  instantiation  method  as  the 
block  object.  The  required  fields  are  the  number  of  subordinate  components,  the  number 
of  subordinates  required  to  operate  and  the  number  of  subordinate  blocks.  Using  Figure 
B-l,  there  are  three  subordinates  to  this  system,  two  are  components  and  the  other  is  a 


63 


block.  All  three  are  required  for  the  system  to  operate  therefore  the  next  three  entries  to 
the  input  file  are  2,  3  and  1 .  This  would  create  two  components  and  one  block 
subordinate  to  the  system. 

A  component  object  also  inherits  the  instantiation  method  of  the  block  object. 
Thus  the  creation  of  the  first  of  these  component  objects  would  first  require  the  number 
of  subordinate  components,  the  number  required  and  the  number  of  subordinate  blocks. 
Since  we  are  at  the  component  level  there  are  no  subordinates,  making  these  entries  0,  0 
and  0.  The  component  object  also  calls  another  method  to  set  values  to  its  additional 
fields,  which  are  its  part  number,  MTBF  and  MTTR.  Thus  the  next  entries  are  1,  500.0 
and  2.0.  The  part  number  entry  must  be  alphanumeric  while  the  MTBF  and  MTTR 
entries  must  be  real  numbers.  The  second  component  would  be  created  by  the  entries 
0,0,0,2,  250.0  and  4.0. 

The  next  step  of  the  input  file  would  create  block  three  of  our  sample  system. 
This  block  consists  of  two  subordinate  blocks  and  requires  that  only  one  of  these  blocks 
be  operational.  Thus  the  next  entries  in  the  input  file  would  be  0,  1,  2.  These  entries 
would  create  two  additional  blocks  (3 1  and  32).  Block  3 1  consists  of  two  components 
that  are  connected  in  parallel,  thus  only  one  of  them  has  to  be  operational  for  the  block  to 
continue  to  be  operational.  Thus  the  next  entries  would  be  2,  1,  0.  The  subordinate 
components  would  then  be  created  with  the  following  entries:  0,  0,  0,  3 1 1,  450.0,  4.5,  0, 
0,  0,  312,  200.0,  2.3.  Block  32  consists  of  two  components  that  are  connected  in  series. 
Since  both  are  required  to  maintain  the  block,  the  next  entries  would  be  2,  2,  0.  The 
subordinate  components  would  then  be  created  by  the  following  entries:  0,  0,  0,  321, 
200.0,  3.1,  0,  0,  0,  322,  100.0,  1.2.  Following  the  completion  of  the  system,  the  next  ship 
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would  be  created  and  the  process  would  repeat  itself  until  all  the  ships  in  the  battlegroup 
were  created.  The  final  input  file  for  the  example  shown  in  Figure  B-2. 


Input  File 

3 

48 

360 

720 

1 

2 

720 

!  2 

3 

1 

!  o 

0 

0 

1 

500.0 

2 

!  0 

0 

0 

2 

250.0 

4 

I  o 

1 

2 

!  2 

1 

0 

!  o 

0 

0 

311 

450.0 

4.5 

!  o 

0 

0 

312 

200.0 

2.3  | 

2 

2 

0 

0 

0 

0 

321 

200.0 

3.1 

0 

0 

0 

322 

100.0 

1.2  [ 

1 

2 

720 

I  2 

3 

1 

I  o 

0 

0 

1 

500.0 

2  ! 

0 

0 

0 

2 

250.0 

4  | 

I  o 

1 

2 

\    2 

1 

0 

o 

0 

0 

311 

450.0 

4.5  I 

I  o 

0 

0 

312 

200.0 

2.3  ! 

2 

2 

0 

I  o 

0 

0 

321 

200.0 

3.1  | 

!  o 

0 

0 

322 

100.0 

1.2 

I  1 

2 

720 

I  2 

3 

1 

!  o 

0 

0 

1 

500.0 

2 

!  o 

0 

0 

2 

250.0 

4  | 

0 

1 

2 

I  2 

1 

0 

I  o 

0 

0 

311 

450.0 

4.5 

I  o 

0 

0 

312 

200.0 

2.3 

!  2 

2 

0 

I  o 

0 

0 

321 

200.0 

3.1 

I  o 

0 

0 

322 

100.0 

1.2 

Comments 

Initiates  Battlegroup 
Intiates  Ship  1 
Creates  the  System 
Component  1 

Block  3 
Block  31 
Component  31 1 
Component  312 
Block  32 
Component  321 
Component  322 
Intiates  Ship  2 
Creates  the  System 
Component  1 

Block  3 
Block  31 
Component  31 1 
Component  312 
Block  32 
Component  321 
Component  322 
Intiates  Ship  3 
Creates  the  System 
Component  1 

Block  3 
Block  31 
Component  311 
Component  312 
Block  32 
Component  321 
Component  322 


Figure  B-2  Sample  System  Input  File 
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APPENDIX  C:  BSSM  SINGLE  SHIP  OPT  LIST 


uipment 

Part  Number 

System  Ao 

I 

Jnit  Cost 

Cumulative  Cost 

0006 

7019023 

0.695158 

$ 

408.00 

$ 

408.00 

0006 

7020534 

0.69944 

$ 

224.00 

$ 

632.00 

0014 

7017481 

0.699866 

$ 

8,292.86 

$ 

8,924.86 

0006 

M81 940/4-3 

0.728684 

$ 

100.00 

$ 

9,024.86 

0006 

7020611 

0.729056 

$ 

1,100.00 

$ 

10,124.86 

0006 

7020540 

0.735131 

$ 

224.00 

$ 

10,348.86 

0014 

7017487 

0.737378 

$ 

2,092.35 

$ 

12,441.21 

0015 

7017481 

0.750183 

$ 

8,292.86 

$ 

20,734.07 

0011 

7017720 

0.76026 

$ 

5,175.48 

$ 

25,909.55 

0018 

7017511 

0.775957 

$ 

2,760.20 

$ 

28,669.75 

0018 

7017490 

0.810896 

$ 

8,308.81 

$ 

36,978.56 

0022 

7018431 

0.811293 

$ 

276.69 

$ 

37,255.25 

0020 

7017490 

0.820291 

$ 

8,308.81 

$ 

45,564.06 

0018 

7017505 

0.823545 

$ 

2,798.81 

$ 

48,362.87 

0022 

7018169 

0.832241 

$ 

4,503.90 

$ 

52,866.77 

0022 

7017692 

0.837537 

$ 

6,461.79 

$ 

59,328.56 

0020 

7018152 

0.847754 

$ 

9,189.36 

$ 

68,517.92 

0007 

7017819 

0.849105 

$ 

8,298.78 

$ 

76,816.70 

0006 

7019821 

0.849977 

$ 

500.00 

$ 

77,316.70 

0016 

7017615 

0.855281 

$ 

2,760.00 

$ 

80,076.70 

0011 

7017854 

0.867366 

$ 

21,233.81 

$ 

101,310.51 

0006 

7017750 

0.875994 

$ 

9,006.41 

$ 

110,316.92 

0016 

7017609 

0.879008 

$ 

2,784.46 

$ 

113,101.38 

0006 

7017826 

0.883884 

$ 

2,674.31 

$ 

115,775.69 

0015 

7017688 

0.888408 

$ 

10,789.06 

$ 

126,564.75 

0006 

7019010 

0.889475 

$ 

1,000.00 

$ 

127,564.75 

0016 

7017508 

0.896652 

$ 

2,932.09 

$ 

130,496.84 

0017 

7017664 

0.898803 

$ 

10,955.19 

$ 

141,452.03 
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uipment 

Part  Number 

System  Ao 

Unit  Cost 

Cumulative  Cost 

0016 

7017612 

0.900141 

$ 

2,799.00 

$ 

144,251.03 

0020 

7018345 

0.901278 

$ 

5,175.00 

$ 

149,426.03 

0006 

7019338 

0.901338 

$ 

4,200.00 

$ 

153,626.03 

0015 

7017529 

0.903384 

$ 

7,674.48 

$ 

161,300.51 

0015 

7017733 

0.903822 

$ 

3,672.84 

$ 

164,973.35 

0007 

7017747 

0.9089 

$ 

9,208.98 

$ 

174,182.33 

0015 

7017535 

0.910287 

$ 

5,874.36 

$ 

180,056.69 

0016 

7017591 

0.911495 

$ 

4,893.25 

$ 

184,949.94 

0014 

7019037 

0.91282 

$ 

3,750.24 

$ 

188,700.18 

0016 

7017573 

0.913929 

$ 

11,535.56 

$ 

200,235.74 

0016 

7017579 

0.918943 

$ 

12,837.90 

$ 

213,073.64 

0006 

7018895 

0.919576 

$ 

408.00 

$ 

213,481.64 

0017 

7017664 

0.922063 

$ 

10,955.19 

$ 

224,436.83 

0014 

7017496 

0.922899 

$ 

11,084.96 

$ 

235,521.79 

0014 

7017493 

0.927306 

$ 

20,182.81 

$ 

255,704.60 

0018 

7017623 

0.928503 

$ 

9,243.98 

$ 

264,948.58 

0016 

7017588 

0.930083 

$ 

6,236.06 

$ 

271,184.64 

0015 

7017532 

0.930811 

$ 

8,099.68 

$ 

279,284.32 

0016 

7017582 

0.933085 

$ 

7,305.00 

$ 

286,589.32 

0016 

7017585 

0.934409 

$ 

10,609.24 

$ 

297,198.56 

0020 

7017727 

0.936363 

$ 

51,883.00 

$ 

349,081.56 

0016 

7017594 

0.942227 

$ 

13,744.97 

$ 

362,826.53 

0016 

7017576 

0.944716 

$ 

11,444.61 

$ 

374,271.14 

0016 

7017567 

0.946679 

$ 

33,618.00 

$ 

407,889.14 

0015 

7017538 

0.949497 

$ 

21,465.81 

$ 

429,354.95 

0016 

7017570 

0.950048 

$ 

16,472.03 

$ 

445,826.98 

68 


APPENDIX  D:  BSSM  BATTLEGROUP  OPT  LIST 


Equipment    Part  Number    System  Ao    Unit  Cost        Per  Ship  Cumulative  Cost 


0006 
0006 
0014 
0006 
0006 
0006 
0014 
0015 
0011 
0018 
0018 
0022 
0020 
0018 
0022 
0022 
0020 
0007 
0006 
0016 
0011 
0006 
0016 
0006 
0015 
0006 
0016 
0017 


7019023 

7020534 

7017481 

M81 940/4-3 

702061 1 

7020540 

7017487 

7017481 

7017720 

7017511 

7017490 

7018431 

7017490 

7017505 

7018169 

7017692 

7018152 

7017819 

7019821 

7017615 

7017854 

7017750 

7017609 

7017826 

7017688 

7019010 

7017508 

7017664 


0.851976 

0.852123 

0.852129 

0.868896 

0.869184 

0.870676 

0.871161 

0.877238 

0.879649 

0.881542 

0.888301 

0.911328 

0.909527 

0.912391 

0.915402 

0.918956 

0.923513 

0.92381 

0.924002 

0.92486 

0.928494 

0.933755 

0.938414 

0.939424 

0.938582 

0.939594 

0.940911 

0.943697 


$  408.00 
$  224.00 
$  8,292.86 
$  100.00 
$  1,100.00 
$  224.00 
$  2,092.35 
$  8,292.86 
$  5,175.48 
$  2,760.20 
$  8,308.81 
$  276.69 
$  8,308.81 
$  2,798.81 
$  4,503.90 
$  6,461.79 
$  9,189.36 
$  8.298.78 
$  500.00 
$  2,760.00 
$21,233.81 
$  9,006.41 
$  2,784.46 
$  2,674.31 
$10,789.06 
$  1,000.00 
$  2,932.09 
$10,955.19 


52325.116 
52692.316 
52893.916 
60357.49 
60447.49 
61437.49 
61639.09 
63522.2 
70985.78 
75643.71 
78127.89 
85605.82 
85854.84 
88373.77 
92427.28 
98242.89 
106513.3 
108986.5 
116455.4 
116905.4 
119389.4 
138499.8 
146605.6 
149111.6 
151518.5 
161228.6 
162128.6 
164767.5 
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Equipment    Part  Number   System  Ao    Unit  Cost        Per  Ship  Cumulative  Cost 


0016 

7017612 

0.943915 

$  2,799.00 

0020 

7018345 

0.946759 

$  5,175.00 

0006 

7019338 

0.945953 

$  4,200.00 

0015 

7017529 

0.945021 

$  7,674.48 

0015 

7017733 

0.946108 

$  3,672.84 

0007 

7017747 

0.946706 

$  9,208.98 

0015 

7017535 

0.945862 

$  5,874.36 

0016 

7017591 

0.947112 

$  4,893.25 

0014 

7019037 

0.947464 

$  3,750.24 

0016 

7017573 

0.948455 

$11,535.56 

0016 

7017579 

0.947209 

$12,837.90 

0006 

7018895 

0.951329 

$  408.00 

174627.2 
177146.3 
181803.8 
185583.8 
192490.8 
195796.4 
204084.4 
209371.4 
213775.3 
217150.5 
227532.5 
239086.6 
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APPENDLX  E:  PROPOSED  ALLOWANCE  LISTS 


Shipboard  Allowance  List 


3art  Number  Quantity      Unit  Cost 

Cumulative  Cost 

7017481             2          $    8,292.00 

$ 

16,584.00 

7017487 

I          $    2,092.00 

$ 

18,676.00 

7017490 

I          $    8,308.00 

$ 

26,984.00 

7017505 

I          $    2,798.00 

$ 

29,782.00 

7017511 

I          $    2,760.00 

$ 

32,542.00 

7017514 

I          $    2,747.00 

$ 

35,289.00 

7017609 

I          $    2,784.00 

$ 

38,073.00 

7017615 

I          $    2,760.00 

$ 

40,833.00 

7017664 

I          $  10,955.00 

$ 

51,788.00 

7017692 

I          $    6,461.00 

$ 

58,249.00 

7017720 

I          $    5,175.00 

$ 

63,424.00 

7017750 

I          $    9,006.00 

$ 

72,430.00 

7017819 

l          $    8,298.00 

$ 

80,728.00 

7017826 

I          $    2,674.00 

$ 

83,402.00 

7017854 

I          $21,233.00 

$ 

104,635.00 

7018152 

I          $    9,189.00 

$ 

113,824.00 

7018169 

I          $    4,503.00 

$ 

118,327.00 

7018431 

I          $       276.00 

$ 

118,603.00 

7019023 

1           $       408.00 

$ 

119,011.00 

7019821 

1          $       500.00 

$ 

119,511.00 

7020534 

1          $       227.00 

$ 

119,738.00 

7020540 

1          $       224.00 

$ 

119,962.00 

702061 1 

1          $    1,100.00 

$ 

121,062.00 

M-81 94043 

1          $        100.00 

$ 

121,162.00 
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Battlegroup  Allowance  List 


Part  Number  Quantity       Unit  Cost 


Cumulative  Cost 


7017481     2 

!    $ 

8,292.00 

7017487     1 

$ 

2,092.00 

7017490     1 

$ 

8,308.00 

7017505     1 

$ 

2,798.00 

7017511     1 

$ 

2,760.00 

7017514     1 

$ 

2,747.00 

7017609     1 

$ 

2,784.00 

7017615     1 

$ 

2,760.00 

7017664     2 

!    $ 

10,955.00 

7017692     1 

$ 

6,461.00 

7017720     1 

$ 

5,175.00 

7017750     1 

$ 

9,006.00 

7017826     1 

$ 

2,674.00 

7017854     1 

$ 

21,233.00 

7018152     1 

$ 

9,189.00 

7018169     1 

$ 

4,503.00 

7018431     1 

$ 

276.00 

7019023    : 

2    $ 

408.00 

7019821     1 

$ 

500.00 

7020534    : 

?    $ 

227.00 

7020540 

I    $ 

224.00 

702061 1     1 

$ 

1,100.00 

M-81 94043    ; 

2    $ 

100.00 

7017774     1 

$ 

4,476.00 

7018924 

I    $ 

3,700.00 

7017482 

I    $ 

74,809.00 

$  16,584.00 

$  18,676.00 

$  26,984.00 

$  29,782.00 

$  32,542.00 

$  35,289.00 

$  38,073.00 

$  40,833.00 

$  62,743.00 

$  69,204.00 

$  74,379.00 

$  83,385.00 

$  86,059.00 

$  107,292.00 

$  116,481.00 

$  120,984.00 

$  121,260.00 

$  122,076.00 

$  122,576.00 

$  123,030.00 

$  123,254.00 

$  124,354.00 

$  124,554.00 

$  129,030.00 

$  132,730.00 

$  207,539.00 
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Battlegroup  Allowance  List  (Cont'd) 
Part  Number  Quantity       Unit  Cost  Cumulative  Cosl 


7017570 

I    $ 

16,472.00 

$  224,011.00 

7017538 

I    $ 

21,465.00 

$  245,476.00 

7017567 

I    $ 

33,618.00 

$  279,094.00 

7017576 

I    $ 

11,444.00 

$  290,538.00 

7017594 

I    $ 

13,744.00 

$  304,282.00 

7017727 

I    $ 

51,883.00 

$  356,165.00 

7017585 

I    $ 

10,609.00 

$  366,774.00 

7017582 

I    $ 

7,305.00 

$  374,079.00 

7017532 

I    $ 

8,099.00 

$  382,178.00 

7017588 

I    $ 

6,236.00 

$  388,414.00 

7017623 

I    $ 

9,243.00 

$  397,657.00 

7017493 

I    $ 

20,182.00 

$  417,839.00 

7017496 

I    $ 

11,084.00 

$  428,923.00 

7018895 

I    $ 

408.00 

$  429,331.00 

7017579 

I    $ 

12,837.00 

$  442,168.00 

7017573 

I    $ 

11,535.00 

$  453,703.00 

7019037 

I    $ 

3,750.00 

$  457,453.00 

7017591 

I    $ 

4,893.00 

$  462,346.00 

7017535 

I    $ 

5,874.00 

$  468,220.00 

7017747 

I    $ 

9,208.00 

$  477,428.00 

7017733 

I    $ 

3,672.00 

$  481,100.00 

7017529 

I    $ 

7,674.00 

$  488,774.00 

7019338 

I    $ 

4,200.00 

$  492,974.00 

7018345 

1    $ 

5,175.00 

$  498,149.00 

7017612 

1    $ 

2,799.00 

$  500,948.00 

7017508 

1    $ 

2,932.00 

$  503,880.00 

7019010 

1    $ 

1,000.00 

$  504,880.00 

7017688 

1    $ 

10,789.00 

$  515,669.00 

7017826 

1    $ 

2,674.00 

$  518,343.00 

7017819 

1    $ 

8,298.00 

$  526,641.00 
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